Mobility in connection with communication networks is often a precondition. The ability to move within a network and/or between various networks is particularly desirable in connection with mobile wireless terminals, e.g. such as cell phones or such as laptops etc provided with WLAN functionality or similar. A similar mobility is often desired for other terminals, e.g. such as wired Personal Computers (PCs) or similar terminals or nodes that can be perceived as mobile or at least as substantially mobile depending on the particular installation etc.
As is well known to those skilled in the art, a solution for providing mobility in connection with the Internet and similar networks has been provided by the Internet Engineering Task Force (IETF). To this end the IETF has standardized a communication protocol called Mobile IP, or simply MIP. Mobile IP allows mobile devices to move from one network to another while maintaining a permanent IP-address. The basic features of Mobile IP are e.g. described in the IETF specification RFC 3344. Updates are e.g. described in IETF specification RFC 4721 and further developments are e.g. described in the specification RFC 3775.
Mobile IP provides an efficient and scalable mechanism for roaming within the Internet and similar networks. Through the use of Mobile IP a node may change its point-of-attachment to the network without changing its IP-address. This allows the node to maintain transport and higher-layer connections while moving between networks. Mobile IP is most often found in wired and wireless environments where users need to carry their mobile devices (Mobile Nodes) across multiple networks that are reached on different IP-addresses. Mobile IP may for example be used in roaming between overlapping wireless systems, for example between WiFi, WiMax and/or 3G telecommunication networks and similar.
FIG. 1 is a schematic illustration of an exemplifying and well known Mobile IP system 100, e.g. based on the IETF specification RFC 3344. As can be seen in FIG. 1 the system 100 comprises a Mobile Node 110, a Home Agent 112, a Foreign Agent 122 and a Correspondent Node 120. Various designs of the Mobile Node 110 (MN), the Home Agent 112 (HA), the Foreign Agent 122 (FA) and the Correspondent Node 120 (CN) are well known per se to those skilled in the art and there is no need for a detailed description. Nevertheless, short background will be provided below.
As can be seen in FIG. 1 the MN 110 is arranged to operatively communicate with the HA 112 or the FA 122 via the home network 114 or the foreign network 124 respectively. In turn, the HA 112 and the FA 122 are arranged to communicate with each other via a communication network 130 (e.g. the Internet or similar). In addition, the HA 112 is arranged to operatively communicate with the CN 120 via said communication network 130. In particularly, the HA 112 and the FA 122 are arranged to operatively enable communication between the MN 110 and the CN 120 over the network 130, irrespective whether the MN is connected to the home network 112 or the foreign network 124.
The exemplifying MN 110 in FIG. 1 may be a terminal, a host or a router or similar that changes its point of attachment from one network or sub-network to another without changing its IP-address with respect to nodes that may communicate with the MN 110, e.g. such as the CN 120. In this way the MN 110 can continue to communicate with other Internet nodes and similar at any location using its (constant) IP-address. Here, it is assumed that a link-layer connectivity to a point of attachment is available and that the MN 110 comprises suitable hardware and software, e.g. in the form of a interface that is suitable for utilizing the available link-layer connectivity, and a client that enables the MN 110 to access the network in question and nodes or similar that are available therein as is well known to those skilled in the art.
The exemplifying HA 112 in FIG. 1 may be a router or similar connected to the home network 114 of the MN 110. The HA 112 serves as the anchor point for communication with the MN 110. In particular, the HA 112 tunnels data packets or similar for delivery to the MN 110 when the MN 110 is away from its home network 114. In the exemplifying system 100 shown in FIG. 1 the HA 112 tunnels packets received from the CN 120 and addressed to the MN 110 at its Home Address (HoA), by forwarding the packets to a Care-of-Address (CoA) via a tunnel 132 established between the HA 112 and the FA 122, which is the reachable point for the MN 110 in the foreign network 124. Such tunneling is well known to those skilled in the art.
The exemplifying FA 122 in FIG. 1 is preferably a router or similar that operates as the point of attachment for the MN 110 when the MN 110 roams to the foreign network 124. In other words, the FA 122 is preferably a router in the foreign network 124 visited by the MN 110, which router provides mobility services to the MN 110 while registered. The FA 122 de-tunnels and delivers the data packets to the MN 110 that were tunneled by the HA 112 of the MN 110.
The CN 120 may be a peer or similar with which the MN 110 is communicating. The CN 120 may be mobile or stationary.
The following steps provide an exemplifying outline of the discovery and registration phase of the Mobile IP protocol in the exemplifying Mobile IP system 100 shown in FIG. 1.                a) The mobility agents (i.e. the FA 122 and the HA 112 enabling mobility for the MN 110) advertise their presence to the MN 110. As is well known, this can e.g. be done by means of Agent Advertisement messages or similar, which e.g. may comprise at least one Care-of-Address (CoA) and a flag indicating whether the mobility agent is a Home Agent or a Foreign Agent.        b) The MN 110 receives at least one of these advertisements and determines whether it is located on its home network 114 or on the foreign network 124.        c) If the MN 110 detects that it is located on the home network 114 it may operate without mobility services. If returning to its home network 114 from being registered elsewhere, the MN 110 deregisters with its HA 112 through the exchange of Registration Request and Registration Reply messages or similar as is well known.        d) If the MN 110 detects that it has moved to the foreign network 124 it registers with the FA 122 by sending a Registration Request message or similar, which includes the permanent IP-address (the HoA) for the MN 110 and the IP-address for the HA 112 of the MN 110. In turn, the FA 122 performs the registration process on behalf of the MN 110 by sending a Registration Request or similar containing the permanent IP-address for the MN 110 and the IP-address (the CoA) for the FA 122 to the HA 112. As indicated above, the CoA can be provided by the FA 122 in its advertisement messages (i.e. a foreign agent CoA) or by some external assignment mechanism such as DHCP or similar. The transportation of the MN 110 to the foreign network 124 is illustrated in FIG. 1 by a MN 110 with dashed lines at the home network 114 and a dashed arrow to the MN 110 with solid lines at the foreign network 124.        e) When the HA 112 receives the Registration Request message or similar from the FA 122 it updates its home list or similar by associating the CoA of the MN 110 with the HoA of the MN 110.        f) The HA 112 then sends an acknowledgement to the FA 122.        g) The FA 122 in turn updates its visitor list or similar by associating the HoA and/or the address for the HA 112 of the MN 110 with a media address for the MN 110 valid on the foreign network 124 and relays the reply to the MN 110.        
The following steps provide an exemplifying outline of the service phase of the Mobile IP protocol in the exemplifying Mobile IP system 100 shown in FIG. 1.                1. When the CN 120 wants to communicate with the MN 110, it sends an IP packet addressed to the permanent IP-address (the HoA) of the MN 110.        2. The HA 112 then intercepts the packet and consults its home list or similar to find out whether the MN 110 is currently visiting any other network, e.g. finds out whether there is a CoA registered for the MN 110.        3. Assuming that the HA 112 encounters a CoA registered for the MN 110 it will construct a new IP header that contains the CoA of the MN 110 as the destination IP-address. The original IP packet comprising the HoA of the MN 110 is put into the payload of this IP packet. The HA 112 will then send a down-link packet to the CoA. This process of encapsulating one IP packet into the payload of another IP packet is known as IP-within-IP encapsulation, or tunneling. This has been illustrated in FIG. 1 by a tunnel 132 extending from the HA 112 to the FA 122.        4. When the encapsulated packet reaches the foreign network 124, the FA 122 decapsulates the packet and finds out the HoA of the MN 110. The FA 122 then consults its visitor list or similar to see if it has an entry for the MN 110.        5. If there is an entry for the MN 110 in the visitor list, the FA 122 retrieves the corresponding media address and relays the packet to the MN 110 via the foreign network 124.        6. When the MN 110 wants to send an up-link packet to the CN 120, it forwards the packet to the FA 122, which in turn relays the packet to the CN 120 using normal IP routing.        
If needed, the MN 110 and the FA 122 can employ a so-called reverse tunnel in the up-link by tunneling packets from the MN 110 to the HA 112, which in turn forwards them to the CN 120. This is illustrated in FIG. 1 by a reverse tunnel 132′ extending from the FA 122 to the HA 112.
Reverse tunneling is well known to those skilled in the art and the IETF specification RFC 3024 gives an illustrative example. Reverse tunnelling can e.g. be requested by the MN 110 in a registration request or similar sent to the FA 122 when accessing the foreign network 124. The FA 122 will then update its visitor list or similar, including an indication that the MN 110 has been granted a reverse tunnel. In turn, the HA 112 receiving a registration request or similar from the MN 110 via the FA 122 will update its home list or similar, including an indication that the MN 110 has been granted a reverse tunnel. Incoming traffic from the MN 110 sent to the CN 120 will then be tunnelled by the FA 122 to the HA 112 using the CoA as the address of sender (i.e. at this stage the HoA of the MN 110 is capsulated and not use as the address of sender). Incoming traffic from the FA 122 will then be decapsulated by the HA 112, which recovers the original packet and forwards it to the CN 120 on behalf of the MN 110 (i.e. at this stage the HoA of the MN 110 and not the CoA of the FA 122 is use as the address of sender).
The use of reverse tunneling reduces the risk for so-called spoofing. To elaborate the concept of spoofing it can be noticed that the header of each IP packet contains, among other things, the numerical source and destination address of a packet. The source address is normally the address of sender. By forging the header so that it contains a different IP-address, an attacker can make it appear that the packet was sent by another sender. The receiver that receives spoofed packets will send response back to the forged IP-address. In some cases it may e.g. be possible for the attacker to see or redirect the response to his own machine.
The principles of reverse tunneling as indicated above in an exemplifying manner apply mutatis mutandis to a foreign agent (FA) that is co-located with the MN 110 (co-located FA). An example of a co-located foreign agent (FA) will be described below with reference to FIG. 2
In contrast to the exemplifying network in FIG. 1, other networks may not have an explicitly designated FA or similar. Instead an Access Router (AR) or similar may be used for providing access for a mobile node to the network in question.
FIG. 2 is a schematic illustration of another exemplifying and well known Mobile IP system 200. The system 200 in FIG. 2 is substantially the same as the system 100 in FIG. 1. Hence, the same or similar reference numbers indicate the same or similar features. However, as can be seen in FIG. 2 the FA 122 in FIG. 1 has been replaced by an access router AR 222. Here, the foreign agent (FA) or similar can be perceived as located in the MN 210 (A co-located FA). Moreover, the tunnel 132 in FIG. 1 has been replaced by the tunnel 232 extending all the way to the MN 210 in FIG. 2. The fact that the MN 210 serves as the endpoint of the tunnel 232 is illustrated in that the tunnel 232 continues from the AR 222 to the MN 210 (e.g. to the FA co-located in the MN 210), instead of ending at the FA 122 as in FIG. 1. In the reverse direction, a reverse tunnel can be established in the same manner as previously described with reference to the reverse tunnel 132′ in FIG. 1. However, as is well known to those skilled in the art, a reverse tunnel in the system 200 will extend from the MN 210 and its co-located FA all the way to the HA 112. Hence, in the system 200 the FA or similar being co-located with the MN 110 performs the same or similar tasks as the FA 122 in system 100 previously described with reference to FIG. 1.
The structure and function of the Mobile IP systems 100, 200 are well known to those skilled in the art and they are e.g. described in the IETF specification RFC 3344 and its ancillary specifications and in similar documents from the IETF and others. Hence, there is no need for a more detailed description of the general and well known structure and function of the Mobile IP systems 100, 200. However, specific details associated with embodiments of the present invention related to Mobile IP and similar will be discussed later herein.
As described above, it is assumed that the MNs 110, 210 in the systems 100, 200 respectively have the well known Mobile IP capability to signal its location to the Home Agent 112 so as to maintain a permanent IP-address while the MNs 110, 210 move from one network to another. In other words, i.e. the MNs 110, 210 maintains a permanent IP-address with respect to the CN 120 or similar nodes that may communicate with the MN 110, 210.
From the above it can be deducted that the MN 110, 210 located in a foreign network 124, 224 will always establish a downlink tunnel 132, 232 to be used by the HA 112 when forwarding packets from the CN 120 to MN 110, 210 via the FA 122 or similar. In addition, to reduce the risk for spoofing attacks etc, it is frequently preferred that the MN 110, 210 located at a foreign network 124, 224 establishes a reverse tunnel 132′ to be used by the HA 112 when forwarding packets from the MN 110, 210 to the CN 120 via the FA 122 or similar.
However, tunnelling (e.g. an IP-within-IP encapsulation) of the aforementioned kind or similar will always involve tunnelling-overhead, e.g. encapsulation and decapsulation requiring extra processing and the transmission of additional headers etc. Overhead in the form of additional headers etc is particularly disadvantageous with respect to the scarce resources available when communicating over an air interface, which frequently is the case for the communication between the MN 110 and the home network 114, and the communication between the MN 110 and the foreign network 124, 224.
In addition, it frequently happens that the MN 110, 210 has access to the HA 112 via both the foreign network 124, 224 and the home network 114. This may e.g. be the case if the home network 114 is a local network (e.g. a hot spot) and the foreign network 124, 224 is a regional or global network at least covering parts of the home network 114. Known solutions provide no mechanism for avoiding tunnelling so as to optimize the routing path for the communication between a Mobile Node (MN) and a Home Agent (HA). Indeed, known solutions provide none or insufficient optimizing of the routing path for the communication between a Mobile Node (MN) and a Home Agent (HA) where several routing paths are available—including tunnelling and no tunnelling on a single connection as well as tunnelling or no tunnelling on several different connections.
Hence, it would be beneficiary to provide a solution wherein tunnelling can be avoided or only used if it is necessary. In particular, if both tunnelling and no-tunnelling can be used simultaneously it would be beneficiary to be able to select the most favourable alternative.
More generally, it would be beneficiary to be able to select the most favourable routing alternative in the up-link and in the down-link.